Not Applicable
The present invention is related to the field of computer systems, and more particularly to the processing of input/output (I/O) requests to storage devices in computer systems.
Traditionally, in robust operating system environments, the direct manipulation of an interface to one or more storage devices such as disk drives has been reserved for a software module known as a xe2x80x9cdevice driverxe2x80x9d that resides in a base of trusted operating system code. The device driver is designed to obey all the requirements of the operating system and the device for which it is responsible. In these systems, an application program makes I/O requests to the operating system, which in turn sends commands to the device via the device driver. Among other functions, the device driver and operating system detect and reject improper requests. Thus, an I/O request from an application is verified and handled in a manner that guarantees correct behavior for the operating system and the device.
Permitting application programs to directly access a device has been viewed as unsafe, because application programs can inadvertently or maliciously operate the device in a manner causing damage to the device, to other application programs, or to the operating system. An improperly programmed device can read from memory for which an application program lacks sufficient privilege, or overwrite critical sections of memory, such as operating system code or another user""s data. Thus, a device can be used, accidentally or maliciously, to obtain privileged data; to corrupt or destroy data; to deny service to other applications; or to crash the entire system. For this reason, device drivers tend to become part of the trusted code base of the operating system, and application programs are forced to perform I/O via the operating system and the trusted device driver in the manner described above.
Another reason for embedding device drivers in the operating system is to present uniform interfaces to applications, free of the details and vagaries of the various types of devices that an application program may rely on. This feature may be referred to as xe2x80x9cabstractionxe2x80x9d of the devices. The use of abstracted interfaces enables application programmers to concentrate on the important application-specific features of the program, rather than the mechanics of storing and retrieving data from myriad storage devices.
Unfortunately, the traditional paradigm of routing all application program I/O requests through the operating system comes with a performance penalty. Typically, numerous steps are performed between the time an application program makes an operating system call and the time that the desired I/O request is actually posted to a device. These steps can include the following:
Crossing a hardware protection boundary
Saving state for the calling program
Invoking a system call handler
Copying arguments across the hardware protection boundary
Invoking generic device request code
For small amounts of data, copying the data across a hardware protection boundary
For large amounts of data, locking down portions of the calling program""s virtual memory, and translating virtual addresses into physical addresses usable by the device
Invoking device request code in the device driver
Returning through various software layers and across the hardware protection boundary to the calling program
The execution of so many steps consumes valuable system resources such as CPU time, and affects the performance of the application program, as measured for example by latency or throughput (I/O operations or instructions per second). The performance impact is of course more significant for those application programs that are I/O intensive, such as for example real-time video applications or large database applications.
It would be desirable to improve the I/O performance of application programs without sacrificing the protection and abstraction benefits of the traditional I/O paradigm.
In accordance with the present invention, a technique by which an application program directly accesses a storage entity such as a disk in a safe manner is disclosed. This xe2x80x9csafe devicexe2x80x9d access technique enables the application program to bypass the operating system and the device driver for data transfers, resulting in increased performance. The safe device access technique employs an abstracted device interface, as well as protection features to prevent an application program from accidentally or purposely damaging other application programs or other elements of the computer system. The safe device access technique also supports so-called xe2x80x9clegacyxe2x80x9d application programs and devices by using mediation components that provide translation to and from existing programming and device interfaces.
In the disclosed technique, both a virtual memory region allocated for use by the application program and an xe2x80x9cextentxe2x80x9d, or region, of a storage entity to be accessed by the program are registered with a host bus adapter via which the storage entity is accessible. A virtual interface between the application program and the storage entity is then created. The virtual interface includes a queue for transmitting commands from the application program to the storage entity.
When the application program is to perform an I/O request, the program creates one or more data buffers in the registered virtual memory region, the data buffers being allocated for storing either read or write data associated with the command. The application program also creates a descriptor which contains command information identifying the I/O operation to be performed by the storage entity, virtual memory address information identifying the locations of the data buffers in the registered virtual memory region, and storage address information identifying an area within the registered extent to or from which data is to be written or read in accordance with the I/O operation. The application program then posts the descriptor to the virtual interface, by placing the descriptor on the associated queue.
The adapter monitors all virtual interfaces to determine whether their queues contain any posted descriptors. Upon finding a posted descriptor, the adapter verifies that the descriptor and the data buffers identified by the virtual memory address information are located within the registered virtual memory region. The adapter also verifies that the area on the storage entity identified by the storage address information in the descriptor is within the registered extent. If both of these verification steps are successful, then a command for the I/O operation is forwarded to the storage entity for execution. If either verification step fails, then the command is not forwarded to the storage entity, and optionally some indication of this failure is returned to the user or the operating system.
Other aspects, features, and advantages of the present invention are disclosed in the detailed description that follows.